home *** CD-ROM | disk | FTP | other *** search
/ FishMarket 1.0 / FishMarket v1.0.iso / fishies / 176-200 / disk_185 / iff_news < prev    next >
Text File  |  1992-05-06  |  9KB  |  191 lines
  1.                              IFF News 11/88
  2.                              ==============
  3.                          Carolyn Scheppner - CBM
  4.  
  5.  
  6. FORMS and Chunks not in the original EA IFF specs
  7. =================================================
  8.  
  9. A "Registry" document has been added to the IFF specs.  The Registry
  10. contains lists of all registered chunks and forms, and notes on
  11. additions and changes to the specs of the original EA forms and their
  12. chunks.
  13.  
  14. Form specifications for registered public third-party forms will
  15. appear in the Third-Party section of the IFF manual.  However, due 
  16. to the proliferation of application-specific forms, future IFF manuals 
  17. might only contain forms in use by more than one company's products.  
  18.  
  19.  
  20. Creating and Registering New FORMs and Chunks
  21. =============================================
  22.  
  23. Authors who wish to create new forms or chunks are strongly urged to
  24.  
  25.   - Collaborate with other software authors and CBM on their design
  26.   - Choose unique names and reserve them with CBM to avoid conflicts
  27.   - Register all new forms and chunks with CBM
  28.  
  29. Authors should remember special-purpose chunks are usually lost when
  30. an IFF FORM is loaded into another application and saved back out.
  31. The IFF spec states that IFF writers must not write back chunks that
  32. they don't understand because inconsistencies could be created in
  33. the FORM.
  34.  
  35. The current CBM contact for registration of IFF FORMs and chunks is:
  36.  
  37.    Carolyn Scheppner - CATS/IFF
  38.    CBM
  39.    1200 Wilson Drive
  40.    West Chester, PA.  19380   U.S.A.
  41.  
  42.    UUCP: {allegra|rutgers|uunet}!cbmvax!carolyn
  43.    BIX:  cscheppner  (proposals may be posted/discussed in amiga.dev/iff)
  44.  
  45.  
  46. 3. The embedded ILBM forms in an ANIM do not adhere to the ILBM spec
  47.    and technically should have had a different chunk ID.  They do
  48.    not contain the required ILBM property BMHD, and instead contain
  49.    an ANHD and delta information for changing the previous image.
  50.    This inconsistency occurred because the original ANIM concept of
  51.    sequential ILBMs was slowly modified, for speed and compactness,
  52.    into a single ILBM followed by frames containing encoded animation
  53.    changes.  After much discussion with the authors and third parties
  54.    supporting the ANIM form, it was decided that this inconsistency
  55.    must remain for now to avoid breaking existing products. 
  56.  
  57.  
  58. ILBM Problem Areas
  59. ==================
  60.  
  61. Thanks to John Bittner of the Zuma Group for organizing much of this 
  62. information in our amiga.dev/iff conference on BIX.
  63.  
  64. 1. PageWidth and PageHeight - Overscan or Not ?
  65.  
  66.    There are two sets of variables in an ILBM which describe the size
  67.    of the picture.  The image dimensions are stored in w and h.  The
  68.    other two variables, pageWidth and pageHeight, have been interpreted
  69.    in different ways by the various applications which create ILBMs.
  70.  
  71.    The ILBM spec describes them as follows:
  72.  
  73.    "The size in pixels of the source "page" (any raster device) is stored 
  74.    in pageWidth and pageHeight, e.g. (320,200) for a low resolution Amiga
  75.    display.  This information might be used to scale an image or to
  76.    automatically set the display format to suit the image.  (The image can
  77.    be larger than the page.)"
  78.  
  79.    DPaintII stores the normal Amiga screen size in pageWidth and pageHeight,
  80.    and the image size (which may be larger) in w and h.  Up until now,
  81.    we have maintained that this is the correct use of these variables
  82.    because it preserves the normal screen dimensions for programs which
  83.    wish to clip or scroll larger images in a normal size display. 
  84.    In addition, storage of the normal screen size makes it possible for
  85.    the correct ViewModes to be determined in the absence of an Amiga
  86.    ViewModes CAMG chunk.
  87.  
  88.    However, a number of other applications which save overscan images
  89.    store the full size of their display ViewPort in the pageWidth and
  90.    pageHeight variables, and there seems to be a growing consensus
  91.    that this is the correct use of these variables.  This approach is
  92.    non-Amiga-specific and preserves the artist's intent of the size
  93.    raster in which the image was meant to be displayed.  
  94.    
  95.    For now, flexible ILBM readers should be prepared to deal with
  96.    with either alternative, and must parse CAMG chunks for the
  97.    correct Amiga ViewModes.  If a CAMG chunk is not present, ViewModes
  98.    must be guessed based on the pageWidth and pageHeight.  For 1.3
  99.    viewmodes, width greater than or equal to 640 can be assumed HIRES, 
  100.    and height greater than or equal to 400 assumed LACE.  These
  101.    assumptions may be incorrect for future viewmodes.  
  102.  
  103.    
  104. 2. The Use and Misuse of the CAMG chunk
  105.  
  106.    The "optional" ILBM chunk CAMG holds the Amiga ViewModes for displaying
  107.    the image contained in an ILBM.  
  108.    
  109.    With the current variety of overscan storage methods, and the introduction
  110.    of HAM and HALFBRITE paint packages, it is extremely important that
  111.    all Amiga ILBM readers and writers save and parse this chunk.  I have
  112.    actually seen HALFBRITE ILBMs with NO CAMG chunk!  I guess the reader
  113.    programs are supposed to see that it's 6 bitplanes and toss a coin to
  114.    decide if it's HAM or HALFBRITE.   Please store CAMG chunks in all
  115.    ILBMs and parse them when reading ILBMs.  
  116.  
  117.    When saving and parsing the CAMG chunk, you should be aware that certain
  118.    ViewMode bits can cause problems for display programs which use the
  119.    CAMG contents directly for Screen or View modes.  The following
  120.    Amiga Viewmode bits should be masked out when reading or writing
  121.    a CAMG chunk:  SPRITES, VP_HIDE, GENLOCK_AUDIO, and GENLOCK_VIDEO.
  122.    The reserved high word of the CAMG must currently be written as
  123.    zero but not assumed to be zero when read.
  124.  
  125.  
  126. 3. CRNG Color Cycling chunks - Active or Not ?
  127.  
  128.    DPaintII, by default, usually saves CRNG chunks which contain cycle
  129.    ranges and are marked as active, regardless of whether a picture is 
  130.    meant to be cycled.  This makes it impossible for a cycling display
  131.    program to reliably identify ILBMs which should not be cycled.  
  132.    Internally, DPaintII interprets a cycle rate <= 36 (RNG_NORATE)
  133.    to mark a cycle range as non-active.
  134.    
  135.  
  136. 4. How many colors should a CMAP contain ?
  137.  
  138.    There seems to be a great deal of variation in the size of the CMAP
  139.    stored in HAM ILBMs by various applications.  Some store only the
  140.    number of absolute colors used in that particular HAM ILBM.  Programs
  141.    that do this must be really careful about following the IFF spec
  142.    rules regarding the padding between odd-sized chunks.  Some store the
  143.    maximum number of absolute colors in a HAM display (16).  Some store
  144.    a full palette of 32, and many may store a palette of 64 because the
  145.    supplied IFF example code generically uses 1<<bitmap->depth when
  146.    calculating the size CMAP to write.  ILBM display programs must be
  147.    careful to not blindly accept and set the number of color registers
  148.    provided in a CMAP.    
  149.    
  150.  
  151.  
  152. A Word about Compatibility
  153. ==========================
  154.  
  155.    There have been several incidences of new ILBM graphic products
  156. going to market and then being found incompatible with major existing
  157. ILBM graphic software.  Before releasing any product which saves IFF
  158. files of any type, please test the compatibility of your files by
  159. loading them into the major existing software products which read
  160. and write files of the same type, and try loading the files created by
  161. other applications.  If you do not have access to a large number of
  162. these other products, try to find people who do and arrange file exchanges
  163. and compatibility tests.  If your product adapts to PAL screen sizes
  164. or clock rate (important in audio period calculations), arrange for
  165. your product to also be tested on a PAL system.  
  166.  
  167.    Be especially careful if you are not using the EA supplied IFF reading,
  168. writing, and compression routines.  This can sometimes lead to the creation
  169. of subtly out-of-spec IFF files which are rejected by products which use 
  170. the IFF code supplied by EA.  Some examples would be odd length chunks
  171. not followed by a pad byte or a reader not designed to handle pad bytes.
  172. Another would be a badly compressed ILBM.  The EA compresser is smart and
  173. does not encode a scan line if encoding would result in more bytes.  The EA 
  174. decompressor expects a smartly compressed file, and will return an error if 
  175. handed an encoded line more than one control byte larger than destination 
  176. scan line.  If you are not using the EA IFF code, please make sure that your
  177. code follows all of the rules.
  178.  
  179.      
  180.  
  181. Future IFF
  182. ==========
  183.  
  184.    We hope to see a shared run-time iff.library sometime this year, through
  185. a coordinated effort between CBM and third-parties.  Core IFF reading and
  186. writing routines will probably be in an IFF.library, with form-specific 
  187. routines in separate modules or libraries.  An IFF.library would take a
  188. lot of the code burden off of applications and would be especially useful
  189. for programmers using languages other than C.
  190.  
  191.